A computer includes a CPU (Central Processing Unit) and a device which are connected each other via a system bus (hereinafter, referred to as ‘bus’ in some cases), and accesses the device according to an instruction of a program executed on the CPU. The access to the device is referred to as ‘input/output process’ or ‘I/O process’. Meanwhile, software which controls the device is referred to as an ‘OS (Operating System)’. Especially, software, which controls the device, out of OSs is referred to as a ‘device driver’. Moreover, a plurality of user programs are executed on the OS by control of the OS. In order that the user program may not access the device directly, there is a difference in execution authority between the OS and the user program.
Xeon® or Atom of Intel Corporation are examples of the CPU. Linux®, Windows® of Microsoft Corporation or the like is an example of the OS. Moreover, PCI (Peripheral Component Interconnect), PCI-Express or the like is an example of the system bus. Furthermore, a hard disk drive (HDD), a network interface card (NIC), and the like are examples of the devices.
The devices are scanned at a start-up time of the computer by BIOS (Basic Input/Output System), and are assigned IDs (Identifiers), memory areas and the like. At this time, the devices are not in an available state. After a start-up of the OS, by a device driver working for a device, to be operated by the OS, out of scanned devices, the device is initialized. By executing the initialization, the device enters into the available state. A set of ‘bus number/device number/function number (BDF) is an example of ID, and it is possible to uniquely specify the device, which is connected with the computer, by using the set. This set is a logical number, and may be changed in some cases according to the number, a configuration, or a scanning order of the devices.
As a method for accessing the device for the running OS, two access methods are known. That is, one is the access method by issuing an I/O instruction and the other is the access method by MMIO (Memory-Mapped I/O). According to the former method, the I/O instruction is defined as an instruction set of the CPU. Therefore, the I/O instruction is outputted on the bus by the program's issuing the CPU instruction, and the access to the device is executed. Meanwhile, according to the latter method, when the OS accesses a specified memory address, the CPU or a chipset which controls the bus converts the memory address into an I/O process and outputs the I/O process on the bus. As a result, the access to the device is executed. As mentioned above, when BIOS scans the devices, since a size of memory space which the device requests is assigned in physical memory space, a memory access to the assigned physical memory space is converted into the I/O instruction. Hereinafter, the above-mentioned two methods for device access are collectively referred to as ‘I/O instruction’. When accessing the device, the memory address, ID or the like which identifies the device is designated by the I/O instruction.
Recently, CPU's advance in performance permits some software overheads. Consequently, it is possible to make hardware virtualized, and to make a plurality of virtual hardware environments work on a single CPU.
FIG. 9 is a block diagram exemplifying a configuration of a virtualized computer which makes such virtual hardware environments work. The OS which manages the virtual hardware environment shown in FIG. 9 is referred to as a host OS X110. Meanwhile, the OS which is executed in the virtual hardware environment is referred to as a guest OS. While the number of the host OSs X110 is one, it is possible to execute a plurality of the guest OSs (refer to signs X101-X10n). Moreover, the guest OS may be different in a kind from the host OS X110, and the guest OS may be different in a kind from the other guest OSs. As an example of the host OS X110 which provides the virtual hardware environment, kvm, VMWare® or the ESXi server of VMWare Inc., or the like is known.
Generally, in the virtualized environment, instead of making the gust OS directly recognize a device B X131 which is connected with the host OS X110, a virtualized device A (hereinafter, referred to as ‘virtual device’) is provided to the guest OS (for example, the guest OS X101). That is, a device driver B, which the host OS X110 has, controls the device B X131. Meanwhile, a device driver A, which the guest OS (for example, the guest OS X101) has, controls the virtual device A. At this time, the host OS X110 converts an I/O instruction, which the device driver A of the guest OS (for example, the guest OS X101) issues, in such a way that a device driver of the device B X131 can decode the I/O instruction.
Meanwhile, PTL 1 discloses ‘pass-through technology’ managing the device by not the host OS but a device driver of the guest. According to the technology described by PTL 1, it is possible that the guest OS in place of the host OS can control some devices which are connected with the computer.
Moreover, PTL 2 discloses a technology for extending the bus virtually. According to the technology described by PTL 2, it is possible to physically extend a distance between CPU and the device by transferring data, which flow on PCI-Express, through a network based on Ethernet® or the like. The PCI-Express bus transfers data in a form of packet. Here, the packet is a unit of a transfer for communication between two points, and generally a source address and a destination address are embedded in the packet.
FIG. 10 is a block diagram showing a configuration of a computer which applies the bus extension technology described by PTL 2. Referring to FIG. 10, according to the technology described by PTL 2, an upstream bridge X140 is arranged to connect to a CPU X120, and a downstream bridge X420 is arranged to connect to a device (peripheral equipment X130). Each of the bridges X140 and X420 encapsulates a packet, and de-capsulates the encapsulated packet (that is, releases encapsulation). By the above-mentioned encapsulation, it is possible to make data on the bus transferred through an Ethernet® network. Since also the Ethernet network transfers data in a form of packet, hereinafter, a packet which flows on a network is referred to as a ‘network packet’.
PTL 3 discloses a method for facilitating connection of a USB (Universal Serial Bus) device in a virtualized environment. Specifically, PTL 3 discloses a virtual bus system having a device management unit which determines whether or not enumeration can be executed by referring to a permission list and a device management table for managing a connection state of another device.